昨天的結尾留了一個問題：流程說明文件負責回答「畫什麼」，繪圖規格文件負責回答「怎麼畫」，但這兩份文件目前仍是獨立的參考資料。每次使用時，都得手動提醒 Claude Code「請依照這份模板」或「請依照這份規格」。

今天就接著處理這個缺口：如何讓 Claude Code 根據使用者的需求，自行判斷該套用哪一套規則，並在需要時讀取對應的文件？答案就是 Skill。

Skill 是什麼：把一套做事方法收進資料夾

一個 Skill 最基本的結構，是一個資料夾加上一份 SKILL.md。視需求不同，資料夾裡還可以放入參考文件、範例或輔助腳本，把完成一項任務會用到的規則與素材集中在同一個地方。

SKILL.md 可以分成兩個部分。開頭是 YAML frontmatter，也就是放在檔案最前面的基本資料；後面則是 Markdown 內容，寫下 Claude 實際執行時要遵循的步驟。

frontmatter 可以記錄 Skill 的名稱、用途、適用情境，以及執行時會使用哪些工具。其中，description 用來說明這個 Skill 能做什麼，when_to_use 則補充什麼情況適合使用。這些簡短說明，正是 Claude Code 判斷目前需求是否與某個 Skill 相關的重要依據。

至於 SKILL.md 的內文，才是完整的做事方法。它可以規定要先讀哪些資料、依照什麼順序執行、什麼情況要詢問使用者，以及完成前需要檢查哪些項目。

先看簡短說明，需要時才讀完整內容

一般對話中，Claude Code 不會一開始就把每一份 SKILL.md 的完整內容全部載入，而是先把可用 Skill 的名稱與說明放進上下文。當使用者的需求與某個 Skill 的說明相符時，Claude 才會載入完整內容，依照裡面的步驟執行。

換句話說，Skill 的運作可以拆成兩個階段：先判斷「現在是否適合使用」，確定相關之後，再讀取完整規則。這樣可以避免所有 Skill 同時占用上下文，也讓 Claude Code 能根據目前的任務，選擇真正需要的指示。

至於資料夾裡的參考文件，也不會因為放進去就自動全部載入。仍然要在 SKILL.md 裡註明每份文件的用途與讀取時機，Claude 才知道何時需要它。

從「手動指定文件」到「自動套用流程」

回到退換貨案例：流程說明模板（Day 20、21）與繪圖規格（Day 22、23）都已經完成，但如果每次都要先輸入「請讀模板，再讀規格，最後才開始畫圖」，負擔其實沒有真正消失，只是從「口述整段流程」變成「口述該讀哪些文件」。使用者仍得記得有哪些文件，以及什麼時候該使用哪一份。

Skill 把這個責任往內收。兩份文件可以放進 references/ 資料夾，再由 SKILL.md 寫清楚：第幾步要讀模板、第幾步要讀繪圖規格、什麼情況要向使用者確認，以及確認到什麼程度才能開始產圖。

使用者只要把需求講清楚，文件選擇與執行順序就能交給 Skill 裡寫好的流程處理。如此一來，使用者不必記住整份文件清單，也不需要每次重新說明應該先做什麼、再做什麼。

為什麼要把參考文件拆出去

流程說明模板與繪圖規格不需要全部寫進 SKILL.md，可以各自獨立成 references/ 底下的文件，再由 SKILL.md 註明何時讀取哪一份。

這樣拆有兩個好處。第一，SKILL.md 可以專心描述互動流程，不必塞進所有細節；Claude 也能在實際需要時才讀取對應文件，減少不必要的上下文用量。第二，模板與規格可以各自修改、持續累積，不必每次都動到 SKILL.md 本身。

也可以把三者的分工理解成：

• frontmatter：幫助 Claude Code 判斷什麼時候適合使用這個 Skill
• SKILL.md 內文：規定要依照哪些步驟執行
• references/：保存流程中需要查閱的詳細規則與模板

這一步解決了什麼

Day 17 提出的三個問題，到了 Day 23，已經透過流程說明文件與繪圖規格，補上「重複口述」、「AI 自行決定畫法」與「缺少驗收基準」這三個缺口。但同時也留下了一個新問題：使用者仍然要記得有哪些文件，以及這次該指定哪一份。

Skill 補的正是這一塊。觸發判斷交給 frontmatter 裡的簡短說明，讀取時機與執行順序則交給 SKILL.md 裡寫好的步驟。Skill 的價值並不是完全拿掉人的控制，而是讓常用的判斷與執行流程不必每次重新交代。

明天會討論一份實際的 SKILL.md，逐段看看這套互動流程是怎麼寫成的。